fix(acp): restrict owner-only trigger authority to the exact owner - #6087

Problem

With respond-to = owner-only, author_allowed admitted same-owner sibling
agents as trigger authority, not just the registered owner. Combined with a
wildcard subscription (subscribe-mode = all leaves kinds empty, which the
filter treats as match-all) and the automatic 👀 "seen" reaction added at
queue-push time, sibling agents in a shared channel could trigger each other's
turns.

Each queued event produced new lifecycle events (kind 7 reactions, kind 20002
typing, kind 5 deletions) that were themselves delivered as work, so the
population of turns grew instead of settling. The 👀 is added before the agent
turn begins and is gated only on whether the event was queued — not on its kind
— so no prompt or persona change can interrupt the cycle.

Change

RespondTo::OwnerOnly now admits only the exact registered owner as automatic
work, in both the DM and non-DM paths. A new private is_owner helper does the
exact-match check; is_owner_or_sibling is retained and still used by
Allowlist and Anyone, whose behavior is unchanged.

Sibling-authored messages remain fully readable as conversation context — the
context parser is untouched, and a test pins that visibility so the fix cannot
silently become a censor.

The production change is confined to crates/buzz-acp/src/lib.rs. The
pool.rs change is test-only.

Tests

Seven tests exercise the real author gate, the real subscription matcher, and
signed Nostr events:

• strict_owner_accepts_owner_kind9_as_work
• strict_owner_rejects_sibling_kind9_as_work
• strict_owner_rejects_self_authored_kind9
• strict_owner_dm_accepts_owner_but_rejects_sibling
• strict_owner_rejects_sibling_lifecycle_kinds_even_when_filter_wildcard_matches
• strict_owner_owner_message_cannot_seed_sibling_reply_chain
• strict_owner_sibling_message_remains_readable_context

The lifecycle test asserts that the wildcard subscription still matches kinds
5/7/20002 while those sibling events no longer reach work, so the fix is pinned
at the author boundary rather than by narrowing the kind filter.

These guards were verified non-vacuous: reverting only the two
RespondTo::OwnerOnly => is_owner(...) arms back to is_owner_or_sibling
fails 4 of the 7 (..._owner_message_cannot_seed_sibling_reply_chain fails
left: 33, right: 1, i.e. 33 events became work where 1 should have).
Restoring returns them to green.

Local results on this branch:

• cargo test -p buzz-acp → 784 passed / 0 failed
• cargo clippy -p buzz-acp --all-targets -- -D warnings → clean
• cargo fmt --all -- --check → clean

Compatibility

This narrows behavior. Allowlist, Anyone, Nobody, setup-mode reuse,
and history-query semantics are preserved, but any deployment that relies on
same-owner sibling agents triggering each other under owner-only will stop
working and must move those pubkeys to Allowlist. Worth a release note.